Ссылки по теме * [Arch Build System (Русский)](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)") * [Arch packaging standards](/index.php/Arch_packaging_standards "Arch packaging standards") * [Arch User Repository (Русский)](/index.php/Arch_User_Repository_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch User Repository (Русский)") * [Creating packages for other distributions](/index.php/Creating_packages_for_other_distributions "Creating packages for other distributions") * [makepkg (Русский)](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") * [pacman (Русский)](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Pacman (Русский)") * [Patching in ABS](/index.php/Patching_in_ABS "Patching in ABS") * [PKGBUILD (Русский)](/index.php/PKGBUILD_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "PKGBUILD (Русский)") * [DeveloperWiki:Building in a Clean Chroot](/index.php/DeveloperWiki:Building_in_a_Clean_Chroot "DeveloperWiki:Building in a Clean Chroot") Документ [ABS - The Arch Build System](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)") дает хороший обзор инструментов и файлов, необходимых для создания и изменения пакетов для Arch Linux. Скорее всего, здесь вы найдете все, что нужно знать для настройки или пересборки существующих пакетов. В то же время, если вам нужно создать новый пакет, существует несколько дополнительных статей, которые помогут вам в этом. Этот документ изначально предполагает, что вы прочитали и поняли описание ABS. ## Contents * [1 Подготовка файлов](#.D0.9F.D0.BE.D0.B4.D0.B3.D0.BE.D1.82.D0.BE.D0.B2.D0.BA.D0.B0_.D1.84.D0.B0.D0.B9.D0.BB.D0.BE.D0.B2) * [2 Редактирование переменных](#.D0.A0.D0.B5.D0.B4.D0.B0.D0.BA.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BF.D0.B5.D1.80.D0.B5.D0.BC.D0.B5.D0.BD.D0.BD.D1.8B.D1.85) * [3 Использование исходного кода](#.D0.98.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.B8.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D0.BE.D0.B3.D0.BE_.D0.BA.D0.BE.D0.B4.D0.B0) * [3.1 Функция build()](#.D0.A4.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D1.8F_build.28.29) * [3.2 Функция package()](#.D0.A4.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D1.8F_package.28.29) * [4 Тестирование PKGBUILD'а](#.D0.A2.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_PKGBUILD.27.D0.B0) * [5 Тестирование пакета](#.D0.A2.D0.B5.D1.81.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.B0) * [6 Резюмируя вышесказанное](#.D0.A0.D0.B5.D0.B7.D1.8E.D0.BC.D0.B8.D1.80.D1.83.D1.8F_.D0.B2.D1.8B.D1.88.D0.B5.D1.81.D0.BA.D0.B0.D0.B7.D0.B0.D0.BD.D0.BD.D0.BE.D0.B5) * [7 Полезные ссылки](#.D0.9F.D0.BE.D0.BB.D0.B5.D0.B7.D0.BD.D1.8B.D0.B5_.D1.81.D1.81.D1.8B.D0.BB.D0.BA.D0.B8) * [8 Внимание](#.D0.92.D0.BD.D0.B8.D0.BC.D0.B0.D0.BD.D0.B8.D0.B5) * [9 Более подробные указания](#.D0.91.D0.BE.D0.BB.D0.B5.D0.B5_.D0.BF.D0.BE.D0.B4.D1.80.D0.BE.D0.B1.D0.BD.D1.8B.D0.B5_.D1.83.D0.BA.D0.B0.D0.B7.D0.B0.D0.BD.D0.B8.D1.8F) ## Подготовка файлов Вся информация для создания пакета помещена в файл `PKGBUILD`. Когда вы запускаете `makepkg`, он ищет `PKGBUILD` в текущей рабочей директории и затем собирает приложение из исходного кода, следуя инструкциям в `PKGBUILD`. После успешной компиляции полученные бинарные файлы, как и вся необходимая метаинформация (такие как версия пакета и зависимости), архивируются в пакетный файл `имя.pkg.tar.gz`, который легко может быть установлен при помощи команды `pacman -Up <имя_файла_пакета>`. Файл `PKGBUILD` содержит **все** инструкции для создания пакета, которые напрямую интерпретируется оболочкой bash (не бойтесь, если ничего не поняли). Переменные, используемые здесь, определены в статье [ABS](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)"), но наиболее важные/сложные переменные также описаны и здесь. Чтобы создать новый пакет, сперва вы должны создать пустую директорию; предпочтительней назвать ее `/var/abs/local/<ИМЯ_ПАКЕТА>`. В этом случае пакет отлично интегрируется в нормальное ABS-дерево и не затрагивается cvsup, даже когда вы обновляете дерево. Перейдите в директорию пакета и создайте файл `PKGBUILD` путем копирования прототипа файла пакета `/usr/share/pacman/PKGBUILD.proto`, либо скопируйте `PKGBUILD` из другого пакета. Последний способ быстрее, если вам нужно изменить опции компиляции для пакета вместо создания нового. Тем не менее с этого момента вам нужен файл `PKGBUILD` для продолжения работы. ## Редактирование переменных Откройте файл PKGBUILD и установите значения следующих переменных в зависимости от пакета, который вы собираете: * **pkgname:** Здесь находится название пакета. Можно использовать только строчные английские буквы. Значение этой переменной большой роли не играет, но может помочь, если установить сюда имя рабочей директории, или, например, имя файла с исходным кодом (*.tar.gz), который требуется загрузить * **pkgver:** Здесь находится версия пакета. Эта переменная может содержать буквы, цифры, знаки препинания, **но не может содержать дефисов ("-")**. Содержимое этой переменной зависит от метода присвоения версий (major.minor.bugfix, major.date, и т.д.) который использует программа. Чтобы следующие шаги были наиболее эффективными и лёгкими, рекомендуется включить номер версии в имя файла с исходным кодом. Внимание! Если разработчик пакета использует дефисы в номере версии, замените их на символы подчёркивания. ('0.99-10' => '0.99_10') * **pkgrel:** Значение этой переменной представляет из себя число, которое нужно увеличивать каждый раз после новой сборки пакета. При первой сборке пакета значение pkgrel должно быть установлено в "1". Цель этой переменной состоит в том, чтобы различать разные сборки пакета одной и той же версии. *Например: вы собрали пакет и позже обнаружили, что в исходном коде была ошибка. Вы исправили исходный код, но посчитали не нужным увеличивать версию пакета. **Вместо этого можно увеличить значение pkgrel. Результат: pacman будет знать, что пакет требует переустановки.*** Когда к сборке будет готова следующая версия пакета (с измененным **pkgver**), значение переменной **pkgrel** нужно сбросить в "1". * **pkgdesc:** Здесь должно быть краткое описание пакета, обычно не более 76 символов. Учтите, что *краткость - сестра таланта*: `OpenGL accelerated X server` лучше чем `xgl is an OpenGL...`. * **arch:** Здесь должен быть список архитектур, где может быть использован данный PKGBUILD (обычно это "i686"). Значение данной переменной будет записано в `$arch` и может быть использовано далее в процессе сборки. * **url:** Здесь должен находиться адрес веб-сайта программы, где заинтересовавшиеся могут получить более подробную информацию о программе. * **license:** Тип лицензии. Если сомневаетесь, пишите 'unknown' * **depends:** Список пакетов, разделенный пробелами, которые должны быть установлены до использования пакета. Во избежании проблем, имена пакетов заключаются в апострофы ('), а весь массив в скобки. Используя математическое "больше или равно", можно указать минимальную допустимую версию пакета-зависимости. Пример: пакету требуется glibc и slang, причем slang версии 1.8.0 и выше. **depends`('glibc' 'slang>=`1.8.0')** * **makedepends:** Список пакетов, которые потребуются для сборки пакета, но которые не нужны для его **использования**. Пример: *`unarj` может потребоваться во время установки, чтобы распаковать какие-нибудь патчи.* * **provides:** Список пакетов, необходимость в которых пропадает, так как собираемый пакет выполняет, по крайней мере, похожие функции. * **conflicts:** Список пакетов, которые, если установлены, могут создать проблемы во время использования собираемого пакета. * **replaces:** Список пакетов, которые заменит собираемый пакет. * **source:** Список файлов, которые потребуются во время сборки пакета. Естественно, здесь должна быть ссылка на архив с исходным кодом программы (в большинстве случаев такая ссылка представляет из себя HTTP или FTP ссылку, заключённую в кавычки). Образец `PKGBUILD`-файла демонстрирует, как в названии и версии файла могут быть использованы предыдущие переменные. Если вы обнаружите, что некоторые файлы не могут быть скачены на лету, например, какие-нибудь самопальные патчи, вы можете поместить их в одну и ту же папку с `PKGBUILD`'ом и добавить их имена в список **source**. Любые локальные пути, указанные в этой переменной, будут разрешаться относительно `PKGBUILD`-файла. Перед сборкой, все файлы из этого списка будут проверены и при необходимости загружены; если обнаружатся проблемы, `makepkg` не будет продолжать сборку. * **md5sums:** Список контрольных сумм для файлов из предыдущей переменной, разделенных пробелами и заключённых в апострофы. Как только станут доступны все файлы из списка source, md5 суммы файлов будут автоматически сгенерированны и проверены на соответствие с этим списком. Критическое значение имеет порядок сумм в этой переменной, так как makepkg не будет гадать, какому файлу какая сумма соответствует. К первому файлу из списка source относится первая md5-сумма из списка md5sums, ко второму - вторая, и т.д.. Во избежании путаницы, контрольные суммы могут быть легко и просто сгенерированы командой `makepkg -g` (после того как будет обозначен список source) в директории с `PKGBUILD`'ом. `makepkg -g >> PKGBUILD` сгенерирует md5-суммы и запишет их в конец `PKGBUILD`, откуда они могут быть перемещены в любое другое место `PKGBUILD`-файла. И так, мы установили мета-информацию пакета - список зависимостей, конфликтов, список файлов для загрузки и т.д. Следующие шаги - непосредственная сборка и установка пакета. --[Oleg-A](/index.php?title=User:Oleg-A&action=edit&redlink=1 "User:Oleg-A (page does not exist)") 08:09, 6 July 2008 (EDT) ## Использование исходного кода Теперь вам надо скачать архив с исходным кодом, распаковать его и обратить внимание на команды, необходимые для сборки и установки. Содержимое функции `build()` в вашем `PKGBUILD` будет в точности повторять эти шаги ещё раз, но с небольшими изменениями, чтобы сделать готовый к утановке пакет, как только закончится компиляция. Сейчас вам скорее всего потребуется изменить содержимое функции `build()` в `PKGBUILD` файле. Она использует синтаксис bash и стандартные команды оболочки. Эта функция в основном используется для автоматической компиляции программ. Она создает директорию `pkg`, в которую затем устанавливает программу, позволяя `makepkg` таким образом создать пакет без необходимости использования файлов из остальной части файловой системы. ### Функция build() Обычно первым шагом в этой функции меняют рабочую директорию на одну из созданных при распаковке исходного кода. Для этого вы можете использовать переменную `$startdir`, которая ссылается на директорию с файлом `PKGBUILD`. Вы также можете использовать объявленные `$pkgname` и `$pkgver`. Не используйте `$startdir/src` вместо `$srcdir` и `$startdir/pkg` вместо `$pkgdir`. Варианты с **startdir** устаревшие и неработоспособные с выходом pacman 4.1\. Например, в зависимости от имени распакованной makepkg директории, первая команда в функции `build()` может быть `cd $srсdir/$pkgname-$pkgver`, что бывает очень часто, если только автор программы не очень-очень злой человек. Более сложная часть — компиляция. Предположим, вам удалось вручную собрать программу, так как скорее всего все шаги для этого здесь описать не удастся. В конце концов, это именно то, что её автор должен описать в файлах README и INSTALL. Теперь, когда вы находитесь в нужной директории, вы должны выяснить, какие необходимы команды для сборки пакета. В самых простых случаях можно использовать `./configure; make`, хотя существуют десятки разновидностей, включая `ant build` либо использование команд `gcc` для компиляции. Хорошо то, что если вам уже удалось вручную собрать пакет, то вам всего лишь надо записать команды, которые вы использовали, после чего всё должно работать нормально. Так как множество пакетов любят устанавливать себя в `/usr/local`, а Arch Linux предпочитает использовать только `/usr`, вам, вероятно, захочется задать параметр скрипту configure или команде make, который об этом позаботится. Оригинал `PKGBUILD` служит примером этого, хотя он может работать по-разному. * Часто в `configure` можно указать prefix, который указывает, куда надо устанавливать программу. Например, вы можете использовать в конфигурации `./configure --prefix=$pkgdir/usr`. * Иногда надо указывать `PREFIX` при запуске `make install`. Иногда её задают как переменную, а иногда указывают в команде. В худшем случае, вам придется отредактировать один или несколько Makefile-ов (или файлов с настройками ant, если этот проект использует его) при помощи sed-а или самодельного патча. * Бывают другие типы установочных скриптов, которые позволяют указать место установки программы. Как вы наверно уже догадались, это часть, где приобретенные знания и опыт становятся необходимыми. Очень полезным оказывается просматривание `PKGBUILD`ов в дереве ABS, так как они работают и содержат некоторые трюки, которые могут оказаться полезными. **Note:** Если ваша программа не требует компиляции, НЕ используйте функцию `build()`. Она не является обязательной, а вот функция `package()` - является ### Функция package() Финальный шаг — создание пакета, в современных версиях makepkg (pacman 4.1.0) **package() — главная функция**. Цель функции `package()` — установить скомпилированные файлы в место, где `makepkg` cможет достать их и создать пакет. Это `pkg` директория. Она нужна для имитации корня вашей файловой системы для процедуры установки программы. Все файлы, которые надо установить в вашу файловую систему, должны там находиться в точно такой же структуре директорий(т.е. если вы хотите установить файл `myprog` в `/usr/bin`, его надо поместить в `$pkgdir/usr/bin`). К счастью, мало программ требуют, чтобы пользователь копировал десятки файлов вручную. Вместо этого они предоставляют некоторую процедуру установки, которая делает это автоматически и часто запускается командой "make install". Однако, очень важно чтобы вы знали, как сказать этой процедуре, что она должна поместить все свои файлы не в / , а в `$pkgdir/`! Иначе, вы получите пустой пакет и бинарные файлы установленной программы "правильно" скопированные сразу в систему. В основном, вам надо будет передать параметр prefix вызову make install как показано в оригинальном файле, но также весьма возможно, что программа требует другого подхода: Очень часто программа установки программы создаст нужные директории в `pkg/`. Если же она этого не делает, у вас будет много ошибок на стадии установки, так как файлы будут копироваться в несуществующие директории. В этом случае вам надо будет создать их добавляя команды `mkdir` в функцию `build()` перед запуском процедуры установки. Конечно, структура директорий зависит от пакета: некоторым программам надо поместить свой код в `/etc` или `/usr`, а другие используют `/bin` или `/opt`. **Примечание:** Функция package() может быть единственной функцией в PKGBUILD. Если Ваша задача — только скопировать файлы в нужные каталоги, не делайте это в функции build(), переместите весь функционал в package(). * Иногда, программу надо запускать из одной директории. Тогда следует просто скопировать её в `$pkgdir/opt`. ## Тестирование PKGBUILD'а Когда вы пишете функцию `build()` , вам захочется часто проверять ваши изменения, чтобы убедиться в отсутствии ошибок. Вы можете сделать это, используя команду `makepkg` в директории, содержащей `PKGBUILD`. С правильно отформатированным `PKGBUILD`ом, эта операция создаст пакет. В противном случае появится сообщение об ошибке. Надеемся, что оно будет информативным! Если запуск `makepkg` был успешным, будет создан новый файл $pkgname-$pkgver.pkg.tar.gz в рабочей директории. Этот пакет можно установить, запустив `pacman -U ` или `pacman -A`, а также добавить в локальный или web репозиторий. Заметьте: то, что пакет был создан, не означает, что он работает! Он может содержать только структуру каталогов, если вы неправильно указали prefix. Вы можете использовать функции проверки(query) pacman-а для отображения списка файлов в пакете, его зависимостей и сравнить их с вашими ожиданиями. Это можно сделать, выполнив `pacman -Qlp ` или `pacman -Qip `. Если с пакетом все в порядке, больше ничего делать не нужно. Если же вы планируете опубликовать пакет или PKGBUILD, обязательно проверьте, перепроверьте, а потом перепроверьте еще раз содержимое списка зависимостей. Он должен включать в себя список всех пакетов, которые необходимо установить для нормальной работы вашего пакета. Обязательно должны быть указаны зависимости первого уровня. Например, `gtk2` зависит от `glib2`. Как и большинству программ с открытыми исходниками, написанным на C, ему так же требуется `glibc`. Тем не менее, `glibc` не нужно указывать как зависимость для `gtk2`, потому что это - зависимость `glib2`, а `glib2` уже есть в списках зависимостей для `gtk2`. Существуют разные средства для проверки зависимостей. В том числе, `namcap`, написанный Jason Chu (`pacman -S namcap`), а так же менее известная программа `ldd`. Для дополнительной информации ознакомьтесь со страницами руководства этих программ. Еще можно прочитать документацию к программе и посетить сайт разработчиков (на некоторых есть отдельная страница, на которой указаны зависимости (dependencies)). ## Тестирование пакета Кроме того, убедитесь, что бинарный пакет запускается без ошибок! Это действительно раздражительно выпустить пакет, который содержит все необходимые файлы, но не работает из-за какой-то опции, которая не очень хорошо работает с остальной системой. Если вы собираетесь компилировать пакет только для собственной системы, то вам не нужно слишком беспокоиться по поводу качества этого шага,так как в конце концов вы — единственный человек, страдающий от ошибок. ## Резюмируя вышесказанное * Скачайте архив с исходными кодами программы, которую вы хотите превратить в пакет. * Попробуйте собрать пакет и установить его в произвольный каталог. * Скопируйте прототип файла пакета `/var/abs/PKGBUILD.proto` в файл `PKGBUILD` во временном рабочем каталоге. * Отредактируйте файл PKGBUILD в соответствии с потребностями пакета. * Запустите `makepkg` и убедитесь, что полученный пакет собрался корретно. * В случае неудачи повторите предыдущие два шага. ## Полезные ссылки * [ABS - The Arch Build System](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)") * [makepkg man page](https://www.archlinux.org/pacman/makepkg.8.html) * [makepkg tutorial](/index.php/Makepkg "Makepkg") * [Arch CVS & SVN PKGBUILD guidelines](/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines "Arch CVS & SVN PKGBUILD guidelines") ## Внимание * Прежде чем вы сможете автоматизировать процесс сборки пакетов, надо собрать все вручную хотя бы один раз, чтобы *точно* знать, что вы будете делать заранее. К сожалению, несмотря на то, что большое количество авторов программ придерживаются варианта сборки в три этапа: "./configure; make; make install" - это не всегда самый подходящий вариант. Придерживайтесь правила: если вы не можете скомпилировать программу из архива с исходниками и сделать так, чтобы она самостоятельно устанавливалась в определенную временную директорию, не надо даже пытаться сделать пакет. `makepkg` не сможет совершить великого колдунства, способного убрать недостатки исходников. * В некоторых случаях, пакеты не доступны даже в качестве исходников, и вам придется воспользоваться чем-нибудь типа `sh installer.run` чтобы заставить их работать. Вам придется провести некоторые исследования (почитать README, инструкции по установке, справочные руководства, возможно воспользоваться ebuild-ами из gentoo или другими установщики пакетов, возможно даже MAKEFILE'ами или исходниками). В худшем случае, придется редактировать исходные файлы. Тем не менее, `makepkg` должен быть абсолютно автономным, без пользовательского участия. Так что если есть необходимость редактировать Makefile'ы, возможно вам понадобится сделать отдельный патч с `PKGBUILDом` и устанавливать его из функции `build()`, или можно применить несколько команд с `sed` из этой же функции. * Запомните: то, что пакет был собран успешно, не значит, что он работает! ## Более подробные указания **Указания по созданию пакетов** * * * [CLR](/index.php/CLR_package_guidelines "CLR package guidelines") – [Cross](/index.php/Cross-compiling_tools_package_guidelines "Cross-compiling tools package guidelines") – [Eclipse](/index.php/Eclipse_plugin_package_guidelines "Eclipse plugin package guidelines") – [Free Pascal](/index.php/Free_Pascal_package_guidelines "Free Pascal package guidelines") – [GNOME](/index.php/GNOME_package_guidelines "GNOME package guidelines") – [Go](/index.php/Go_package_guidelines "Go package guidelines") – [Haskell](/index.php/Haskell_package_guidelines "Haskell package guidelines") – [Java](/index.php/Java_package_guidelines "Java package guidelines") – [KDE](/index.php/KDE_package_guidelines "KDE package guidelines") – [Kernel](/index.php/Kernel_module_package_guidelines "Kernel module package guidelines") – [Lisp](/index.php/Lisp_package_guidelines "Lisp package guidelines") – [MinGW](/index.php/MinGW_package_guidelines "MinGW package guidelines") – [Nonfree](/index.php/Nonfree_applications_package_guidelines "Nonfree applications package guidelines") – [OCaml](/index.php/OCaml_package_guidelines "OCaml package guidelines") – [Perl](/index.php/Perl_package_guidelines "Perl package guidelines") – [PHP](/index.php/PHP_package_guidelines "PHP package guidelines") – [Python](/index.php/Python_package_guidelines "Python package guidelines") – [Ruby](/index.php/Ruby_Gem_package_guidelines "Ruby Gem package guidelines") – [VCS](/index.php/VCS_package_guidelines "VCS package guidelines") – [Web](/index.php/Web_application_package_guidelines "Web application package guidelines") – [Wine](/index.php/Wine_package_guidelines_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Wine package guidelines (Русский)")